\section{Threats to Validity}
\label{subsec:threat}

We describe two threats in this paper, the Deadlock Algorithm and the Call Graph
Analysis in Section~\ref{subsec:banker_limit} and
Section~\ref{subsec:callgraph_limit} respectively.

\subsection{Deadlock Algoirthm}
\label{subsec:banker_limit}

The deadlock algorithm has some limitation that may make our deadlock detection
less practical. For example, in using the deadlock algorithm, we would need to
know of a few things in advance such as how much each resource a thread can
request and the total number of threads within the application. However, such
system are not practical in the real world as threads can spawn multiple
instance and each may set its own resources (assuming its sharable by
other threads) dynamically. 

Also, more than two threads can request for the same resource. In implementing
the deadlock detection technique, we emphasize only on two threads having each
resource set at a maximum of one request per time. In reality, the resource is
not necessary one, and it may change dynamically. This will result in a more
complex scenario that we have not taken consideration into. In this report, we
have showed that if we know of all these information in advance and applied the
deadlock algorithm described, we will be able to detect deadlock in using an
aspect language.

In the future, we may research for a better algorithm in detecting the deadlock.
The algorithm should be able to cater for the limitations that was described
earlier.

\subsection{Call Graph Analysis}
\label{subsec:callgraph_limit}

There are many different ways an infinite loop may occur. In this paper, we
make an intelligent guess that a normal program will not call its method for a
certain threshold of time. However, this require the program to execute and it
might waste resources. 

Although we made an intelligent and logical assumption that a method will
not be called more than 1000 times, there is still a possibility that the
programmer would really want to execute a method multiple times beyond the
threshold set by us. This may be due to repeated processing of batch
transactions, probably dealing with millions of records.

There are also other possibilities that an infinite loop might occur, such as
two different threads calling each other repeatedly in a cycle without any break
point. This will indeed cause an infinite loop and in our construction of the
detecting infinite loop, we have not consider such cases.

In the future, we may research for better way to identify the patterns of a loop
for infinite calls before the loop has been executed for a number of times.
